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ABSTRACT 


This research provides a qualitative analysis of the logistics impacts, effects, and 
sustainment challenges presented to the Space Based Space Surveillance Block 10 
System. Two large program changes were the focus of this study: a change in operations 
concept from a contractor operated to a USG/Blue Suit operated system and a change in 
system security level. The qualitative analysis/case study was conducted using the 10 
core Product Support Elements (PSEs) as outlined in the Defense Acquisition 
University’s Integrated Product Support Element Guidebook. Eindings presented that all 
10 of the PSEs were affected, with 6 of the 10 core PSEs requiring substantial 
adjustment. Manpower and Personnel was arguably the PSE most affected by both 
system changes. 
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EXECUTIVE SUMMARY 


This research examines the effects to acquisition logistics and system 
sustainability for Space Based Space Surveillance (SBSS) Block 10 System when 
experiencing significant program changes to the operational concept and security posture. 
As a primary objective, the research presents the challenges for effective SBSS Block 10 
life cycle sustainability that evolved as a result of the planned transition from a contractor 
operated system to a USG/Blue Suit Operated system. As a secondary objective, the 
research offers logistics challenges that were presented by a subsequent change in 
security level. This report also provides findings, results, conclusions, and 
recommendations, as well as presenting areas for future research. 

The research analyzed data from multiple program sources, including system 
briefings and key program documentation such as the SBSS Block 10 Life Cycle 
Management Plan, Concept of Operations, Maintenance Plans, Labs-and-Links Support 
Briefs, and other system support documents. Other source documents included studies 
from the RAND corporation. Defense Acquisition University, and similar supporting 
studies. The main source and methodology for the qualitative logistics analysis was the 
Defense Acquisition University’s Integrated Product Support Element Guidebook. 

First, the SBSS Block 10 system operational concept acquisition logistics 
challenges and changes were presented using the Defense Acquisition University (DAU) 
Product Support Elements (PSEs). It was concluded that all 10 of the PSEs were affected, 
with 6 of the 10 PSEs impacted significantly and arguably the greatest impacts noticed in 
the Manpower and Personnel, Training, and Technical Data areas. All 10 elements 
required consideration for support impacts, with many elements significantly intertwined 
as the program changes evolved. 

Second, the SBSS Block 10 system security level acquisition logistics challenges 
and changes were presented using the DAU PSEs. It was again concluded that all 10 of 
the PSEs were affected, with 4 of the 10 impacted significantly and arguably the greatest 
impacts noticed in the Manpower and Personnel, Eacilities and Infrastructure elements. 
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All 10 elements required consideration for security impacts, with many security level 
changes requiring implementation of logistics related changes across functional areas. 

Finally, the conclusions, and recommendations are presented. The findings from 
the research concluded that the acquisition logistics and sustainment baseline was 
impacted significantly as a result of the operational concept and security level program 
changes. All 10 PSE areas were impacted by these larger program changes, with the 
greatest changes to the Manpower and Personnel, Training and Training Support, and 
Facilities and Infrastructure. Product Support Management and Design Interface are also 
covered, but only in a general manner. Conclusions from the study were then outlined, 
with recommendations for areas of further research to close the report. 
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I. INTRODUCTION 

“You will not find it difficult to prove that battles, campaigns, and even 
wars have been won or lost primarily because of logistics.” 

— General Dwight D. Eisenhower 


Aboard a Minotaur IV launch vehicle, a revolutionary new space situational asset 
dubbed the Space Based Space Surveillance (SBSS) Block 10 satellite, took to orbit on 
September 20, 2010. This satellite was pegged as the next generation augment for the 
Space Situational Awareness battle-space/space fence concept and offered a significant 
enhancement for tracking resident space objects and space object identification. But the 
acquisition was not without challenges, experiencing numerous launch delays, from 
changes in system requirements, technical challenges in space vehicle development, to 
concerns with the launch vehicle and changes in software acquisition strategies. 

Along with and directly tied to these program delays, were substantial program 
changes that subsequently rolled into new logistics and sustainment support challenges. 
The challenges spanned the logistics support elements enterprise, from maintenance and 
facilities/infrastructure to training and manpower. Despite these challenges, the 
government and industrial enterprise worked together to ensure a very complex and 
critical program was launched with a supportable operations and maintenance footprint. 
However, numerous lessons learned can be taken away from the acquisition, specifically, 
how critical program changes to operations and training concepts and security 
environment affected the overall support posture for the system, including potential 
impacts to system product support management. 
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A. BACKGROUND 

1. Space System and Satellite Acquisition 

Space System and satellite acquisition has always been a complex and 
challenging endeavor. The vast types of missions expected from these systems and 
satellites, the cutting edge technology needed to meet this missions, and the expected 
service life for today’s satellites can create nightmares for DOD Program Managers 
expected to meet tighter and tighter budget and schedule constraints while ensuring 
continued system performance and either minimal or zero gap in mission coverage 
between existing and new capabilities. But those challenges can be amplified for a Space 
Product Support Manager or Acquisition Logistician who typically has much less 
decision making authority and even less cost and schedule flexibility. But in order to 
better understand the PSM’s logistics challenges, let’s examine the space system 
acquisition life cycle visually. Figure 1 is an excerpt from the Defense Acquisition 
University Executive Program Management Course presentation (Rosenthal, 2015, slide 
44). 


Life Cycle Cost Categories 


S5SSSS$S5SSSSSS$SS55S$SSSSSSSSSSSSS$SSSSSSSSSSSSSSS$SSSSSSSSSSSSS£SSSSS£SSSSSSSSSSSSSSSSSSSSSSSSSSS$SS5SSS$$SSS$SS55SS£SSSS$SSSSSSS 


Notional % of LCC 


- 16 % 
-53 - 54% 
66 - 68 % 


Space system 
Surface vehicle 


Program 
Cost % 



CE PDRR EMD 


Production, Fielding / Deployment 
& Operational Support 


Figure 1. Space System vs. Traditional System Life-Cycle Cost Comparison. 

Source: Rosenthal (2015). 
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While the actual percentage of system life cycle costs for space acquisition varies 
from study to study (many core/non-space LC cost charts follow a 10-30-60 split for 
R&D, Investment, and Operations and Support respectively), the above chart provides an 
excellent comparison of these core/non-space or satellite systems when compared to most 
space systems similar to SBSS Block 10. Over 80% of space system life cycle cost is 
expended during the R&D and Investment, leaving only 20% for system operations and 
sustainment. However, there are many reasons why this is a logical construct for 
acquiring space systems. 

According to the RAND published “Acquisition of Space Systems: Past Problems 
and Future Challenges,” there are a few important reasons why much of space system life 
cost is dedicated to the R&D and Investment phases. Most space acquisitions include 
low-quantity buys (greatly increasing unit cost), have a limited industrial base (requiring 
highly technical skills with significant levels of education), require very stringent 
standards for components (space qualified with high reliability), are technologically 
complex with limited to no ability to repair hardware on-orbit cost effectively. 
(Axelbrand, et ah, 2015, pp.41-44). For these reasons, up-front expense on satellite 
programs is significant. 

With this in mind, many Program Managers are simply focused on the investment 
and research and development stages, as that is where most of the up front budget and 
schedule is allocated. There is also a mindset among PM’s is that Acquisition Logistics is 
something that can be “fixed later” or assume their Acquisition Logisticians or 
Sustainment Engineers are “handling the issues.” Some PM’s are simply focused on 
keeping the program alive or keeping the program moving (since many USG PM’s are 
only leading a program for 3-4 years) so they can get to operations and sustainment, 
which can certainly make planning for logistics and sustainment challenging, even more 
so when you have less resources (maybe 20% of program’s budget) to address any 
challenges that may arise. To put it simply. Space System Acquisition Logistics and 
Sustainment can be a hair-raising experience. The next section will try to cover the types 
of logistics challenges programs may experience outside of the limited acquisition 
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logistics and operations and sustainment budget and mindset’s that are prevalent in space 
system acquisition. 

2. Space and Satellite System Logistics Support and Sustainment 
Challenges 

As outlined in the previous section, space system and satellite acquisition can be a 
difficult and complex task. The logistics and sustainment aspects can be equally as 
challenging, since many of the repercussions of management decisions must be solved in 
a reactive manner due to the ever-evolving and complex nature of these programs. These 
challenges span the logistics enterprise and although not necessarily specific to space 
programs, they can take on a life of their own. 

One challenge always present is the highly complex and cutting edge nature of the 
space and satellite programs. Many times, acquisition and sustainment logisticians are 
trying to plan to support a system that provides capabilities or is executing a mission not 
seen before. In these cases, parametric analysis of like or similar systems is sometimes 
the best (and only) means to plan for sustainment. The “like systems” science isn’t 
perfect, but it provides a bedrock for solid system support analysis. Another logistics and 
sustainment challenge present in supporting space systems is ensuring planning for 
systems requiring an evolutionary acquisition approach. While it’s possible for some 
ground system footprints that support a satellite to effectively support future satellites or 
satellite capabilities, future capabilities and the infrastructure support for these 
capabilities must be considered. Although requirements may be met for an initial space 
system or satellite spiral, accounting for future spiral capabilities is critical for follow-on 
system success. 

Probably the biggest challenge to space acquisition logistics and sustainment is 
the ever-present danger of a change in requirements (Lorell, 2006, p. 61). Long 
development cycles for space systems generate more opportunities for requirements 
changes, obsolescence, or unanticipated technical problems. Additionally, changes in 
any one system segment often require changes in the other segments with significant cost 
and schedule implications. Acquisition and sustainment logisticians must plan for change 
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as much as possible, and at times, react to these changes as quickly as possible in a 
constrained fiscal environment and time frame. And though adjustments for system 
requirements changes by logistics aren’t always immediately needed, many changes 
require significant lead time and compete with R&D and Investment funding for 
execution (Lorell, 2006, p. 117). 

In an effort to understand some of SBSS Block lO’s logistics and sustainment 
challenges, it is important to review the acquisition history of SBSS Block 10. 

3. MSX-SBV & Space Based Space Surveillance Block 10 Program 
History 

The SBSS Block 10 program was a new program start in FY02 originally 
programmed to follow a normalized acquisition process. However, given a forecasted 
operational gap caused by the expected end-of-life for MSX/SBV (the predecessor/pre¬ 
cursor of SBSS), the SBSS program was given additional funding through an FY03 
Program Decision Memorandum to accelerate SBSS Block 10 and effectively replace the 
MSX/SBV sensor. This acceleration resulted in a unique acquisition strategy and 
contractual structure in order to meet the goal of launching SBSS Block 10 by its original 
target launch date of Dec 2006. Problems with this construct and challenges with satellite 
development necessitated a contract restructure and program re-baseline in 
2006-07 (SMC, 2009). 

The Milestone Decision Authority (MDA) for SBSS was initially delegated from 
Under Secretary of the Air Force (USECAF) to Air Force Program Executive Officer for 
Space, who approved the acquisition strategy for the SBSS Block 10 program in Mar 03. 
Consistent with the original program funding levels and MDA delegation, SBSS was 
designated an ACAT 2 program (SMC, 2009). 

In order to meet the EY03 Program Decision Memorandum (PDM) schedule, the 
government required a streamlined acquisition approach. At that time, Northrop 
Grumman Mission Systems (NGMS) was on contract with the Space Superiority Systems 
Wing (SYSW), providing system and engineering services across the entire SYSW 
portfolio. The contract vehicle also allowed for them to support or lead acquisition efforts 
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such as preparing solicitations, executing source selections, and awarding contracts; this 
construct was put into effect for the SBSS Block 10 effort. NGMS subsequently awarded 
a subcontract to the Boeing/Ball/Harris Team in early 2004 to develop, build, and launch 
the SBSS Block 10 program, after a prolonged source selection due to a change in the 
government strategy for launch vehicle procurement (to the Minotaur IV). The delay in 
contract award shifted the target launch date from Dec 06 to Jun 07 (SMC, 2009). 

Due to cost growth through 2005 and the 3-tiered contractor structure limiting 
government visibility and control, the government and contractor team initiated a 
significant overhaul in program structure. NGMS relinquished the majority of the role as 
prime contractor, retaining only contract administration responsibilities. The government 
negotiated agreements to gain direct access to Boeing as the prime for all but contract 
administration matters. Additionally, Massachusetts Institute of Technology / Lincoln 
Laboratory (MIT/LL) was added to the team to develop and deliver Mission Planning / 
Mission Data Processing (MP/MDP) capability, leveraging their expertise with MSX/ 
SBV. Due to past cost growth, on 22 Dec 2006 the USECAF notified Undersecretary of 
Defense for Acquisition, Technology, & Logistics (USD/AT&L) that SBSS had exceeded 
the cost threshold for Acquisition Category 1 (ACAT 1). (SMC, 2009) As the new 
program Milestone Decision Authority (MDA), USD/AT&L directed generation of an 
Acquisition Program Baseline (APB), and the conduct of an Independent Cost Estimate 
(ICE), an Independent Program Assessment (IPA), and for the program to meet a 
Defense Space Acquisition Board (DSAB). 

During this process, the SBSS program office conducted a detailed Integrated 
Baseline Review (IBR) to set a high-confidence, risk-reduced, and executable cost and 
schedule baseline. This baseline captured system safety elements (including logistics 
support, operations & maintenance, and mission assurance) not built into the original 
program due to budgetary constraints and the original acquisition strategy. The APB 
objective and threshold dates for launch availability are June 09 and December 09 
respectively, with an objective program cost of $825.8M (TY) (SMC 2009). The launch 
was eventually changed to September 2010 due to concerns with the launch vehicle. 
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Thus, a program that was scheduled to take 4 years from inception to launch to almost 8 
years and 3 times the budget. 

4. Summary 

The previous background provides important context for the research that will be 
presented in this report. Both space system and satellite acquisition are difficult 
endeavors with unique life cycle considerations and challenges. These considerations and 
challenges were briefly covered, with a short history of SBSS Block 10 offered for 
additional report context. 

B. PROBLEM STATEMENT 

The Problem Statement for this research is best summarized as outlined in a 
RAND Project Air Fore study authored by Lorell, Lowell, and Younossi: 

“In Evolutionary Acquisition Systems such as SBSS, 

Logistics ends up taking it in the shorts” 

— Random program manager 

While this colorful phrase was made to characterize the evolutionary, or Block 
build nature, of the SBSS System, it’s no less accurate when it comes to how significant 
programmatic changes can affect acquisition and life cycle logistics and system 
sustainment. 

Large program changes can complicate logistics planning (and life-cycle cost 
analysis) by leading to a proliferation of different system logistics challenges. While most 
life cycle logisticians can anticipate and plan for some significant system level changes, 
large program scope changes can create additional complexities and costs that will be 
incurred and may not be affordable under the established program baselines. It is these 
second and third level effects to logistics and sustainment that must be considered when 
moving forward in a space system acquisition such SBSS and the hope is to illustrate 
some of these effects in this research paper. 
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C. RESEARCH OBJECTIVES 

The objective of this research to present the overarching acquisition logistics and 
sustainment impacts that can be experienced by a satellite program when system baseline 
changes are introduced. While these program changes are not typical (operations 
ownership/organizations and security levels are typically decided at program inception), 
the subsequent logistics and sustainment impacts are far from routine. The overarching 
objective is to present the SBSS Block 10 System as a case study for other similar 
systems that may undergo similar operations concept and security requirements changes 
so others can account for similar program changes on future space or satellite systems. 

D. RESEARCH QUESTIONS 

Primary Research Question: The main question of this research is to answer the 
question, “What challenges for effective SBSS Block 10 life cycle acquisition logistics 
and sustainability evolved as a result of the planned transition from a contractor operated 
system to a USG/Blue Suit Operations?” 

Secondary Research Question: The secondary question we outlined is, “What 
logistics and sustainment challenges were presented to the SBSS Block 10 System by the 
change in security level?” 

E. PURPOSE/BENEFIT 

The purpose of this paper is to present changes experienced during the 
development and acquisition of SBSS Block 10 and methodically outline the logistics 
impacts and the challenges that arose from these changes, using the DAU Integrated 
Product Support Elements of Life Cycle Logistics, and qualitatively asses the sustainment 
impact of each change. The overall goal and benefit of this research is to provide 
experienced logistics changes from the SBSS Block 10 acquisition and give other space 
system logisticians an idea of how military operations and program management 
decisions above execution level can affect integrated product support and sustainability at 
the lowest level. This research also provides a foundation of noticeable changes to SBSS 
Block 10 program cost, schedule, and performance that these two major system changes 
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may have impacted. The purpose is not to present every logistics element change or 
exhaustively examined, but outline some of the more noticeable and impactful changes 
that an acquisition logistician may experience in similar circumstances. 

F. SCOPE/METHODOLOGY 

The scope of this research is limited to the SBSS Block 10 satellite system. The 
SBSS Block 10 system in this research refers to the ground segment, space segment, link 
segment, and the supporting labs and sustainment facilities necessary to execute 24 hours 
a day/7 days a week/365 days a year operations and maintenance activities. The 
methodology used for this analysis is qualitative in nature, although some quantitative 
data is also presented to support the analysis. The main analysis tool used for this 
research is the DAU Integrated Product Support Element Guidebook and the Product 
Support Framework presented in that document. The core ten elements outlined in the 
DAU Integrated Product Support Element Guidebook provide the majority of the core 
analysis, with the overarching two elements (Design Interface and Product Support 
Management) mentioned briefly. 

G. THESIS STATEMENT 

This study will present the impacts and challenges that two major changes to 
SBSS Block 10 System acquisition. The focus will be on a significant change in 
operations concept and change in the system security baseline. The analysis is qualitative 
in nature and will use DAU’s 10 core Integrated Product Support Elements to describe 
the logistics and sustainment changes experienced by the Acquisition Logisticians as 
these two major program baselines were implemented. The two overarching elements of 
Product Support Management and Design Interface will be discussed briefly in the 
findings section. 

H. REPORT ORGANIZATION 

Chapter I of this research provides key background information for the research 
presented to included space program life cycle planning, typical space system logistics 
and sustainment challenges, and the SBSS Block 10 system acquisition history. Chapter 
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II presents the main tools used in the research, as well as a system description to provide 
the context for how these tools relate to SBSS Block 10. Chapter III provides a 
qualitative product support element-by-element review for both research questions. 
Chapters IV and V present the findings, results, conclusions and recommendations. 

I. SUMMARY 

This chapter outlined space system life cycle background information for space 
and satellite acquisition and common logistics and sustainment challenges experienced in 
space acquisition. A History of SBSS Block 10 acquisition was also provided to help set 
the stage for the follow-on research questions and objectives, purpose/benefits, scope/ 
methodology, and overarching thesis statement. 
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II. INTEGRATED PRODUCT SUPPORT ELEMENT AND 

SYSTEM REVIEW 


This chapter outlines the basis for the qualitative analysis presented in this 
research paper. The first objective is to present the Defense Acquisition University 
(DAU) Product Support Elements (PSE) used for the analysis, as well as the Eife Cycle 
Eogistics Support Eramework that these PSEs construct. Additionally, the SBSS Block 
10 system description that these PSEs would be analyzed against should also be 
presented to provide the reader with the context needed to understand the impacts to 
sustainability of the system and the individual system components (Space Segment, 
Ground Segment, and Einks) that are required to execute SBSS Block 10’s daily mission. 

A. DEFENSE ACQUISITION UNIVERSITY PRODUCT SUPPORT 

ELEMENT GUIDEBOOK 

Defense Acquisition University (DAU) has long been at the leading edge of 
Acquisition Eogistics and Product Support Studies and Analysis for defense systems. 
Although space systems are inherently different from both an acquisition and sustainment 
perspective, the elements set forth by DAU still serve as an effective means to plan for 
and analyze the support posture. 

The 10 PSEs at the core of this qualitative analysis are outlined below. As part of 
this outline, typical space system applications of these elements are also presented. 
Product Support Management and Design Interface are not covered as part of the core 
PSEs, but are included as the glue that bring these 10 core elements together. The PSE 
space considerations are not comprehensive or all-encompassing, but rather provide the 
author with the context that a typical Product Support Manager, Space Acquisition 
Eogistics Manager, or Sustainment Specialist would have as a general foundation for 
their work. A graphical representation of these elements can be found in Eigures 2 and 3. 
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Figure 2. Two Variations: DAU Integrated Produet Support Elements. 

Source: DAU (2017). 


NOTE: DAU has presented two interpretations of the PSE construct. The first 
focuses on the core ten elements represented in Eigure 2a, with Design Interface and 
Product Support Management as overarching PSEs intertwined with the core 10 PSEs. 
DAU most recently outlines twelve PSEs, with Design Interface and Product Support 
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Management part of the Technical Management and Life Cycle Sustainment, 
respectively, and assessed independently (outlined in Figure 2b). For the purpose of this 
research, we will be focusing on the core ten elements represented in Figure 2a. 

Sustainment Engineering (Technical Management) - “The objective of the 
Sustaining Engineering Element is to support in-service systems in their operational 
environments” (DAU, 2017e). Eor space systems, sustainment engineering typically 
focuses on collection and analysis of operations and maintenance performance data (to 
include root cause analysis and failure and correction action) and system characterization 
Diminishing Manufacturing sources is also another key focus area, with additional stress 
placed on technical refresh and anomaly resolution. 

Supply Support (Eife Cycle Sustainment Management) - “Supply support 
consists of the management actions, procedures and techniques necessary to acquire, 
catalog, receive, store, transfer, issue and dispose of spares, repair parts, and supplies” 
(DAU, 20171). In the context of space and satellite systems, supply support typically 
refers to the initial provisioning efforts, how initial and spare assets are stored at 
production, lab, and operations facilities, and how these assets are transferred and issued. 

Maintenance Planning and Management (Eife Cycle Sustainment Management) - 
“Maintenance planning and management involves developing, implementing and 
managing the maintenance requirements, concept, and detailed procedures for a system” 
(DAU, 2017k). Eor many space and satellite systems, this includes both preventive and 
corrective maintenance actions/procedures needed to keep the system at maximum 
efficiency, as well as an on-orbit maintenance required such as degassing, satellite 
movements, or other space vehicle centric activities. 

Packaging, Handling, Storage, and Transportation (PHS&T) (Eife Cycle 
Sustainment Management) - “PHS&T refers to the combination of resources, processes, 
procedures, design, considerations, and methods to ensure that all system, equipment, and 
support items are preserved, packaged, handled, and transported properly, including 
environmental considerations, equipment preservation for the short and long storage, and 
transportability” (DAU, 2017h). Eor space and satellite systems, this includes Packaging 
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and Handling for Operations Center and Lab Support assets, as well as transportation of 
the space vehicle and launch vehicle to the pre-launch destinations. Environmental 
considerations tend be strictest for the space and launch vehicle development pre-launch, 
with the highest standards paid to clean room conditions. Post-launch focus for PHS&T 
typically stress the safe, secure, and effective movement of ground support assets 
(servers, simulators, computer components, associated spares, etc.). Asset sanitization, 
physical security, and electrostatic discharge protection are paramount. 

Technical Data (Technical Management) - “Technical Data represents recorded 
information of a scientific or technical nature regardless of form or character necessary to 
acquire, operate or support the weapon system” (DAU, 2017g). For space and satellite 
systems, this element is central to maintaining and updating space system operations, 
maintenance, and engineering support documentation. These include operations and 
maintenance checklists, technical orders, and on-orbit engineering books. Secondarily, 
technical data for the ground system (ops floor and maintenance room) drawings are also 
included, but tend to remain fairly static in a post-launch environment. 

Support Equipment (Infrastructure Management) - “Support equipment consists 
of all equipment (mobile or fixed) that is not inherently part of the primary weapon 
system but is required to support the operation and maintenance of the system” (DAU, 
2017i). For space and satellite systems, post-launch support equipment tends to be fairly 
generic and commercially available (multimeters, ESD benches, etc.). Pre-launch support 
equipment can be more specialized, specifically support equipment needed at the launch 
and space vehicle manufacturing facilities. 

Training and Training Support (Infrastructure Management)- For space systems, 
“training and training support includes the policy, processes, procedures, techniques. 
Training Aids Devices Simulators and Simulations (TADSS), planning and provisioning 
for the training base including equipment used to train civilian, contractor, and military 
personnel to acquire, operate, maintain, and support the system” (DAU, 2017f). 

Manpower & Personnel (Infrastructure Management) - “The Manpower and 
Personnel function for space systems involves the identification and acquisition of 
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personnel (military and civilian, contractor and general schedule) with the skills and 
grades required to operate, maintain, and support systems over their lifetime” (DAU, 
2017j). Most manpower and personnel supporting space systems is held at the operations 
ground locations, with additional personnel supporting the space system at the ground 
support labs, depot facilities, and factories. 

Facilities and Infrastructure (Infrastructure Management) - “Facilities and 
infrastructure consists of the permanent and semi-permanent real property assets and 
infrastructure required to support a system, including studies to define types of facilities 
and infrastructure, or facility and infrastructure improvements, location, space needs, 
environmental and security requirements, and equipment” (DAU, 2017d). For most space 
systems, this is focused on the ground station, operations centers, and associated depot 
and lab support facilities that support the ground stations and ops centers. 

Computer Resources (Technical Management) - “Computer resources are the 
information technology resources and infrastructure required to operate and support 
mission critical systems to include manpower, personnel, hardware, software, and 
documentation such as licenses and services” (DAU, 2017a). For space systems, 
especially ground systems, the computer resources requirement is substantial, with 
multiple towers of servers, modems, and data processing equipment to support mission 
execution. The Product Support Management and Design Interface Product Support 
Elements are the “glue” that hold the core 10 elements together. 

Product Support Management (Life Cycle Sustainment Management) - “Product 
Support Management (PSM) is the development and implementation of product support 
strategies to ensure supportability is considered throughout the system life cycle” (DAU, 
2017b). Space systems, from an enterprise PSM perspective, are treated similarly to other 
operational systems in USAF inventory, although the PSM tends to be significantly more 
focused since space systems typically only have a small number of ground support 
locations and satellite systems on a support network (although there are larger systems 
like the Global Positioning System that can be massive in size). 
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Design Interface (Technical Management) - “Design interface is the integration 
of the quantitative design characteristics of systems engineering (reliability, 
maintainability, etc.) with the functional logistics/integrated product support elements” 
(DAU, 2017c). For space systems, there is a substantial focus on the reliability and 
(Insert reference from GAO/Space Ops Study) and maintainability, especially on the 
space vehicles since once they launch, there are no physical means to repair broken 
components (all repairs are typically done with software patches submitted across a 
linked network). 

B. SBSS BLOCK 10 SYSTEM DESCRIPTION 

SBSS Block 10 is a DOD Space Acquisition Category (ACAT) 1C program that 
provides space surveillance capabilities to satisfy Space Situational Awareness (SSA) 
needs of the warfighter. This system represents a significant improvement in SSA for 
Resident Space Objects (RSO) and Space Object Identification. SBSS achieves space 
superiority through the execution of successful Offensive Space Control (OSC) and 
Defensive Space Control (DSC) missions. SSA is the enabling function of OSC and DSC 
missions. To achieve SSA, SBSS employs capabilities with the coverage and sensitivity 
to completely sense the entire area of regard. The level of awareness of the operational 
environment provided by SBSS Block 10 permits commanders to correctly anticipate 
future conditions, assess changes to the operational picture, establish priorities, exploit 
emerging opportunities, and act with a degree of speed and certainty not matched by 
adversaries (Perkins, 2007, p. 2-6). 
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Figure 3. MSX-SBV — The Predeeessor to SBSS Bloek 10. Souree: Gunter 

(2017). 


The mission of SBSS Block 10 is to perform space-based space surveillance 
operations as part of a Family of Systems (FoS) in support of the United State Strategic 
Command Space Control mission. SBSS Block 10 supports space situational awareness 
(SSA) objectives by collecting metric and Space Object Identification (SOI) data of man¬ 
made resident space objects (RSOs). SBSS Block 10 searches on a nominal state vector, 
or on a specified volume or area in space. SBSS Block 10 operates 24 hours a day, 7 days 
a week to serve users who require space situation awareness of deep-space objects. SBSS 
Block 10 contributes data from observations to the Space Surveillance Network to update 
the Space Catalog (Perkins, 2007, p. 5). 

SBSS Block 10 delivers space surveillance capabilities to satisfy SSA needs of 
the warfighter, filling the gap left by MSX/SBV’s end-of-life (EOT) (See Figure X). As a 
new capability, SBSS Block 10 is part of a “Family of Systems,” interoperable with 
existing systems, and enhancing the global reach of command, control, communications, 
computers, and intelligence (C^I) for Air Force Space Control. (Perkins, 2007, p. 2) 

The Space Operations Center (SOC) receives and responds to mission tasking 
from outside agencies. Satellite ground stations (e.g. Air Force Satellite Control Network 

(AFSCN), Universal Space Network (USN)) located within the U.S., U.S. territories and/ 
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or leased facilities located in neutral and allied nations provide the data network. The 
SOC handles the SBSS satellite telemetry, tracking and commanding. Figure 5 below is a 
graphical representation of the SBSS Block 10 System Life Cycle (Cooper, 2011, p. 3). 
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Figure 4. SBSS Block 10 System Life Cycle. Source: Cooper (2011). 

SBSS Block 10 is an end-to-end space control system comprised of three 
segments: a space segment, a ground segment, and link segment. 
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Figure 5. SBSS Block 10 Space Vehicle (SV): Source: Amedee (2007). 

The Space Segment (SS) consists of a single satellite with a spacecraft bus, the 
surveillance sensor(s), and sensor subsystems. The SS also consists of Space Vehicle 
(SV) launch support test equipment which includes the Spacecraft Test Operations 
Console (STOC). The SV encompasses the various subsystems required to provide the 
on-orbit operational capability. The SV is further divided into spacecraft bus and payload 
(both pictured above in Figure 6). 
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Figure 6. SBSS Block 10 MOD Layout. Source: Bacon & Anderson (2009). 


The ground segment (GS) provides satellite control, mission operations, and 
interfaces to users and the command structure (e.g., for SSA) operated from the Satellite 
Operations Center (SOC) in MOD 10. (Bacon/Anderson, 2009, pp. lO-C-5) The Ground 
Segment (GS) consists of a SOC, the associated hardware and software, and the 
supporting organizations. The GS components are: 

• Ground facilities and equipment 

• Data processing 

• Interfaces to communications 

• Maintenance and logistics resources 

• Training and Simulation resources 

The GS provides the focal point for operational command and control of the 
SBSS Block 10 system. The GS is responsible for all aspects of mission and satellite 
space operations, including initial and ongoing on-orbit operations, maintenance, and 
anomaly resolution. The GS is comprised of both dedicated and shared resources. The GS 
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provides the interfaee to reeeive mission tasking and SBSS Bloek 10 operational 
direetion, and to transfer requested observations, data and system status to the requesting 
ageneies. A visual diagram of Ground Station intereonneetivity is presented below. 
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Figure 7. SBSS Block 10 Ground Segment Layout. Source: Bacon & Anderson 

(2009). 


The Links consist of the Air Force Satellite Control Network (AFSCN) uplink and 
down-link and a high-data rate service provider (Universal Space Network) downlink. 
The closed loop communications links provides the infrastructure needed to perform 
command and control (S-Band) and mission operations (S-Band and commercial X- 
band). The mission data links are of sufficient capacity to support mission operations. 

C. SUMMARY 

This chapter provided the DAU PSEs that will be used for the qualitative analysis 
central to this research, as well as the system description that will provide further context 
for how these PSEs were affected by the selected system changes. The next chapter will 
provide the qualitative analysis of the DAU Product PSEs. 
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III. DATA ANALYSIS 


This chapter presents the 10 core PSEs analyzed for the SBSS Block 10 System 
and the qualitative impacts to those PSEs when assessed in reference to the primary and 
secondary research questions presented in Chapter 11. Section A will present the core 
PSEs and the outcomes experienced in regards to those PSEs when the program made the 
decision to transition from contractor to Blue Suit operations. Section B will address the 
secondary research question and present potential challenges or impacts to SBSS Block 
10 PSEs as a result of the program change in security levels. The final two PSEs will be 
addressed in the Eindings and Results details in Chapter IV. 

A. PRIMARY RESEARCH: TRANSITION FROM CONTRACTOR TO 

BLUE-SUIT OPERATIONS: PRODUCT SUPPORT ELEMENT 

ANALYSIS FOR SUSTAINABILITY 

In March 2006, HQ Air Eorce Space Command was designated as operational 
control for the Space Based Space Surveillance Block 10 system and assigned the 1st and 
7th Space Operations Squadrons (1 SOPS/7 SOPS) as the units responsible for carrying 
out day-to-day mission execution. With this designation, the operations concept changed 
from a contractor operated system by Boeing and Ball System specialists to United States 
Air Force Officer and Enlisted crews, or Blue Suit personnel. With this new Blue Suit 
operations concept came numerous changes to the Eogistics and Product Support 
requirements for SBSS Block 10. The data analysis for the core 10 product support 
elements is presented below. 

I. Sustainment Engineering 

Sustainment engineering, or the support of in-service systems in their operational 
configuration, was certainly affected by the transition from contractor operations to 
USAF operations. Instituting Blue Suit Operations changed the way that maintenance 
data would be collected, analyzed, and stored. In a greater and related sense, anomaly 
resolution processes and discrepancy reporting procedures were adjusted to adhere to 
normali z ed Blue Suit operations protocols rather than any contractor established anomaly 
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or discrepancy reporting processes. Finally, additional consideration for system upgrades 
and technology refresh options was now needed, ensuring minimal interruption to Air 
Force and external customer operations and battle rhythms. 

Throughout system inception and development. Program Managers expected that 
contractor maintenance data collection methods would be used throughout the SBSS 
Block 10 System life cycle. This collection of data was to be accomplished on a 
contractor-selected maintenance data collection (MDC) system and if required, reported 
to Air Force higher HQ through a Maintenance Functional Representative stationed at 
AFSPC. However, when Blue Suit operations were dictated, the requirement evolved to 
ensure SBSS Block 10 maintenance data was accounted for on an approved MDC, such 
as the Integrated Maintenance Data Collection System (IMDS) or a properly classified 
system such the Logistics Information and Operations Network (LIONs) (Nelson, 2010, 
Slide 4). While this wasn’t a significant long term complication, this created a duplication 
of maintenance data reporting by the contractor maintenance team until the proper 
database infrastructure was established in the USAF approved system. 

Anomaly resolution and discrepancy reporting was also slightly affected by the 
introduction of Air Force operations. Boeing and Ball Aerospace, for the most part, did a 
great job mirroring Air Force Anomaly Resolution and Discrepancy Reporting processes. 
However, when these processes were initially developed, the contractors assumed their 
main interface for reporting system issues involved both high level 1 and 7 SOPS 
(Operations Officers and Commanders), 50 SW, and AFPSC leaders. When Blue Suit 
crews were introduced, the initial involvement required Air Force incorporation as low 
and the Air Force Crew Commander (typically a Captain or Lieutenant) and required 
inclusion of Air Force crew and support tram members throughout the Anomaly 
Resolution and Discrepancy Reporting processes. While the change was small, it was an 
important change to ensure that USAF personnel were involved in both Space Vehicle 
and Ground System problems as soon as an issue was identified by contractor operations, 
maintenance, and engineering entities. A sample process diagram incorporating Blue Suit 
agencies is presented below. 
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Figure 8. 1-7 SOPS Discrepancy-Anomaly Resolution Process. Source: 

Thompson (2009). 

SBSS Block 10 Technological Refresh and System Upgrade Rules of Engagement 
were also slightly modified due to the change from contractor to Blue Suit operations. 
The plan or systems upgrade or technical refresh would always require significant USAF 
coordination after on-orbit operations commenced because of the requirement to support 
all SBSS Block 10 customers with minimum system downtime. Ground System 
Hardware and Software Upgrade Builds would always have to be done independently of 
the Operations LAN and system battle rhythm, with a large amount of testing and 
interface assessments conducted at the Ground Systems Operations Lab, System Support 
Facilities, or in the final stages, the mirrored Sustainment LAN. However, with the 
introduction of Blue Suit operations, the contractor now had to consider Blue Suit 
Operations, Training and Maintenance events before introducing significant changes to 
the system orientation. Additionally, many of these changes would require significant 
modifications to the technical and training documentation baseline supporting the Blue 
Suit crews. While the overall coordination points would be minimal, the changes to Blue 
Suit support products introduced during a system upgrade or modification are massive. 
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potentially delaying implementation of a system upgrade or technical refresh activity for 
weeks or months. 


2. Supply Support 

Instinctually, many logisticians might think the supply support concept might be 
altered substantially by a change from contractor to Blue Suit operations. However, 
sound supply chain management practices were considered from program inception 
regardless of whether the system was to be operated by contractor or USAF personnel. 
Likewise, initial provisioning for supplies and support equipment, remained consistent 
regardless of the operations concept for SBSS Block 10, with only minimal modification 
to support timelines to account for additional asset processing. 

The main difference between the contractor and Blue Suit operations for Block 10 
supply support was the new level of coordination required when planning to ship assets 
off station and additional cataloguing required to maintain inventories in the appropriate 
supply accounting systems. With the Air Force now managing operations. Air Force 
personnel must also know when system assets will be down and important items will be 
moved off station and into the supply system to ensure the highest mission availability 
(Cooper, 2011, Pages 27-28). Additionally, with the required Air Force operational use 
of the Standard Base Supply System (SBSS) to track some of these assets, the contractor 
was required to catalogue many commercial assets into the supply chain management 
systems required to be used by the Air Force. These changes weren’t substantial, but still 
required consideration for providing logistics supply support. 

3. Maintenance Planning and Management 

Maintenance Planning and Management didn’t change too significantly when the 

Blue Suit Operations were designated instead of contractor operations. Maintenance, in a 

general sense, was always planned to be a contractor performed function. This included 

organizational level maintenance performed on equipment in the MOD 10 equipment 

room, as well as maintenance at the supporting intermediate maintenance locations such 

as Boeing Support Center/Ground Systems Operations Lab in Colorado Springs and 

depot maintenance locations such as the Ball Aerospace Space Vehicle Support Facility 
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in Boulder, Colorado, Ogden Air Logistics Center at Hill AFB, Utah, and MIT Lincoln 
Labs in Lexington, Massachusetts. Despite the lack of change in the relative maintenance 
concept, there were some special considerations that needed to be addressed regarding 
maintenance planning and management. 

One of these considerations was Air Force control of maintenance windows and 
special coordination of maintenance planning windows with outside Air Force and other 
DOD agencies. Because SBSS Block 10 has the flexibility to be tasked in relatively short 
mission planning windows/cycles by multiple outside agencies, maintenance down time 
had to be carefully coordinated to ensure that mission data customers were aware of and 
approved of necessary system down time. While this was anticipated to a certain extent 
anyway since these agencies were always planned as end users/customers of SBSS 
Mission data. Air Force instruction and communications policies needed for Blue Suit 
mission support required additional coordination with 50 SW and Schriever AFB 
Maintenance organizations. Contractor crews would have had additional flexibility to 
conduct maintenance operations that Blue Suit crews would not due to the already 
established external agency reporting requirements. Blue Suit approval and support for 
contractor and maintenance activities could also be required, further lengthening the 
maintenance planning cycles. 

A second maintenance planning and management consideration was the 
contracted reliability and system availability requirements levied on the contractor by 
AFSPC, SMC, and SYSW. Prior to Blue Suit transition, USAF events that could affect 
the contracted system dependability were minimal and the contractor had considerable 
leverage to plan around and schedule any events that may have an effect on the reported 
dependability metrics. However, when USAF personnel were introduced, the contractor 
was required to make additional considerations (especially scheduled USAF maintenance 
and training events) when reporting system uptime and down-time. Additionally, there 
were now other events (like incorporation of 50 SW or unit-level exercises) that could 
effect when the system would be available to be tasked by outside agencies or external 
customers. 
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4. Packaging, Handling, Storage, and Transportation (PHS&T) 

Changes to the PHS&T PSE wasn’t necessarily attributable to the migration from 
contractor to Blue Suit operations. Operations and maintenance locations that were 
established to support Blue Suit facilities would have been established regardless of the 
operations entity. Since many SBSS mission assets remained stationary and permanent 
once installed at the SBSS Block 10 SOC (and some support locations), most shipping 
and handling activities entered around spare commercial assets not yet introduced to the 
system or items that were required at the intermediate support or depot facilities. Some 
pre-launch activities required Blue-Suit escort and specialized handling and containers, 
especially the movement of the space vehicle from factory to the launch site (Cooper, 
2011, pp. 30-32). Occasionally, the requirement for USG/Blue Suit operations escort and 
coordination of classified and sensitive system materials from USAF facilities to 
contractor facilities could affect PHS&T timelines. For the most part, though, changes to 
PHS&T timelines attributable due to the Blue Suit Operations concept, overall, were 
minimal. 

5. Technical Data 

One of the largest changes experienced as a result of designation of Blue Suit 
operations was to the technical data. Not only did the manuals need to move from 
contractor format to Air Force Technical Order (TO) specifications, but numerous 
operations checklists needed to be generated in an effort to expedite and smooth and 
seamless transition to Blue Suit operations. Maintenance and engineering manuals so 
support Anomaly Resolution in a “TO-like” format were also required in the event that 
maintenance operations eventually transitioned to Blue Suit/uniformed personnel. 

During the early development of the Space Operations Center Operations 
Manuals and procedures, Boeing and Ball Aerospace were only required to develop 
manuals to their own company/internal specifications and were generally able to cater the 
manuals to the expected level of education that would be held by their floor operators, 
who typically had a college, graduate, and sometimes postgraduate computer science/ 
engineering degrees and/or significant experience (8-10 years for operations, and up to 
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15-20 years for their back shop and space vehicle engineering positions) in Space 
Operations or Information Technology development. Upon HQ AFSPC assignment of 1 
and 7 SOPS as the operational authority for SBSS Block 10, the technical data strategy 
changed significantly. 

Of particulate note, the background of the designated Air Force operators varied 
significantly from their would-be contractor counterparts. Although perfectly capable of 
handling the SBSS Block 10 mission work-load when provided the proper training, a 
typical USAF space operator expected to pull ground crew duty/and operations floor shift 
had only a high school diploma (and maybe some college) and 5-10 years (sometimes 
less) of actual space operations experience. Their technical school and associated ops 
floor experience provided a solid foundation for them to “learn the ropes” of SBSS Block 
10, but the learning curve was steep and margin for error, even more so. 

In an effort to prepare the Air Force operators for work on a program along the 
complexity of SBSS Block 10, the contractor (with the help 1 and 7 SOPS seasoned 
space operators) began work on streamlined operations checklists and Blue Suit 
Technical Orders that provided step-by-step instructions for routine day-to-day 
operations scenarios. These manuals needed to be written in approved Air Force 
Technical Order format (Nelson, 2010, Slide 7). Once these manuals were certified and 
verified (by a combined contractor and USAF team), they could only be changed using a 
rigid and formali z ed Technical Order change process called the Air Force Technical 
Change Order Form 22 (AFTO 22) process. While contractor data and contractor changes 
to the technical would require a robust change management process as well, the AFTO 
technical data management process is catered to USAF processes and procedures and 
required the contractor support team to issue all future updates in an approved AFTO 
format. 

The Blue Suit Operations team were not the only USAF personnel that needed to 
be accounted for during the system transition. When Blue Suit Engineers were brought 
in to support USAF operations, it was determined that Anomaly Resolution would be 
performed by a combined seasoned contractor and USAF Anomaly Resolution team. In 

this case, the contractor technical documentation supporting back shop engineering 
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required some modifications to accommodate USAF engineers, although this change was 
minimal (only “TO-like’ at most) since most engineers initially brought in to support 
SBSS Block 10 were seasoned in space operations. That being said, Ball Aerospace 
satellite support engineers typically arrived with a more focused engineering background 
and most had significant years of experience in satellite operations/engineering support, 
while USAF Engineers earned degrees spanning from civil, electrical, and aeronautical to 
electrical engineering, requiring some time up front for system familiarization. Overall, 
while the experience levels between contractor and Blue Suit engineers could vary 
substantially, only minor inconveniences existed since Air Force Specialty Code 62E’s 
(Engineering) and Boeing/Ball Space Vehicle Engineers would work together to solve 
any on-orbit issues that may arise. 

6. Support Equipment 

Support equipment for SBSS Block 10, regardless of operations responsibilities, 
did not vary significantly. In some space acquisitions, there are USG/Blue Suit Only 
owned support equipment used in daily operations and sustainment activities (Cooper, 
2011, pp. 27). However, these systems are rare and if they do exist, are many times 
readily available to contractor personnel, especially if the contractor if operated for a 
USG owned/operated facility. Additionally, the contractor is also typically required to 
design space and satellite systems similar to SBSS Block 10 to be supportable with 
standard support equipment, most of which is commercially available. Since most 
satellite ground stations also use a significant amount of commercial equipment (severs, 
computers, cables, racks, etc.) in their design, standard and non-unique support 
equipment is built-in by default. 

7. Training and Training Support 

The training concept supporting SBSS Block 10 changed radically once an Air 
Eorce unit was designated to take over system operations. As mentioned earlier, technical 
documentation supporting the training required significant re-formatting to accommodate 
officer and enlisted USAE personnel. Instead of the engineers that designed the system, 
some with many years of operational experience, the Air Eorce would man the operations 
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center. The education levels and background of the USAF crew commanders and ground 
crews would vary greatly from the contractor manned force, as would the crew construct 
and supporting engineering and backstop engineering expertise. Additionally, an Air 
Force Training Flight/Element/Training Shop was required. Air Force test standards and 
test documentation needed to be established, and any Training Devices required 
certification (also called the SIMCERT process) and creation to Air Eorce training 
standards. 

Since many of the Air Eorce operators would be enlisted with various educational 
backgrounds (from high school education to undergraduate degrees and 5-10 years in 
space operations was the baseline standard), the training documentation used to support 
the SBSS Block 10 training program needed to be generated to support the lowest 
experience and education level of an operations crew member. This was done via a Type- 
1 Training Program, or a Train-the-Trainer, where a small cadre of more experienced and 
educated USAE operators were trained by the contractor, provided contractor courses, 
and given all SBSS Block 10 System documentation to develop an “in-house” training 
program (Colarco, Benz, & Haywood, 2010, p. 30). This small cadre of Air Eorce 
operators then generated their own Air Eorce conducted and maintained training program 
for both current 1/7 SOPS operators or any new operators that may be on the system in 
the future. 

After the USAE training program was developed, a Training Elight needed to be 
established. This shop consisted about three or four USAE Officer and Enlisted personnel 
that were responsible for generating and maintaining all training documentation to 
include crew certification exams, personnel training records, simulator and emulator 
training standards, and all classroom instruction materials. 

The Training Elight (DOUT referenced in Eigure 10 above) also became 

responsible for all Squadron refresher training, currency training for all 1/7 SOPS crew 

personnel, and re-training for any operators that may be have been de-certified on crew 

during on-orbit operations (Colarco, Benz, & Haywood, 2010, pp. 12-15). While the 

Training Shop may have been a small piece of the puzzle, it was a vital function required 

for USAE personnel to ensure continuous and effective SBSS Block 10 on-orbit mission 
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execution since contractor operators would only be needed to maintain training for the 
initial operations period and only for contractor operators. In addition to the change in the 
Training Materials and the Organization needed to maintain them, a USAF certified/ 
approved simulator was also required for steady-state SBSS Block 10 training. Initial 
Type-1 and Air Force Training was conducted using multiple contractor-developed tools 
such the Space Vehicle Simulator, Mission Simulator, On-Board Mission Data 
Processing Tool, and the Sustainment Local Area Network. However, these were mainly 
developed for contractor training use and were not adequate for sustained Air Force 
Training requirements. 


1/7 SOPS - Contractor Organization 
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Figure 9. 1/7 SOPS Contractor Organization and Crew Structure. Source: 

Thompson (2009). 


Air Force Space Command (AFSPC) requires that all Air Force utilized system 
training devices go through a stringent certification and approval process (called 
SIMCERT) before sustained use by Air Force operators. (Colarco, Benz, & Haywood, 
2010, pp. 18-19). Additionally, AFPSC also levied a new requirement on SBSS Block 
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10: a new Space and Missile System Center program called the Standardized Space 
Trainer (SST) that was intended to standardize training simulators across the space 
portfolio. While SST would eventually provide SBSS Block 10 with a Simulator that 
would meet AFSPC SIMCERT requirements, it was a capability that was not budgeted in 
the original program baseline. So while SBSS Block 10 waited for the SST requirements 
to be fleshed out, modifications to the existing contractor training systems were executed 
to meet most SIMCERT requirements, as well technical documentation and training 
waivers to support both Type-1 Training and USAE Training programs. 

8. Manpower and Personnel 

As stated in the Background, the original plan for Block 10 was to have a “turn¬ 
key” system where development and operations contractors were responsible for 
designing, developing, launching, and operating the satellite for an aggressive EY06 
launch deadline. This “Space Cowboys” concept would replace a contractor operated 
extension of the MSX/BV demonstration that had proved itself as a great source of space 
track and ROI data. However, it was limited in maneuverability and was on it’s last legs 
for providing useful operations data. As the utility of MSX/SBV was necessary to 
complement the situational awareness, the Air Eorce stepped in as the agency chosen to 
operate the follow-on system, SBSS Block 10. 

With this new operations agency, the operations concept changed dramatically. In 
order for HQ Air Eorce Space Command and 1/7 SOPS to take control of the system, the 
Blue Suit manpower requirement needed to be generated. After similar space mission and 
parametric manpower analysis, it was projected that it would take around 33 Air Eorce 
manpower billets (11 officer, 22 enlisted) (1-7 SOPS, 2007). HQ AESPC then sent the 
requirement to USAE HQ A1 HQ Air Eorce function (Manpower and Personnel), who 
validated the requirement and allocated needed budget in the Program Objective 
Memorandum (POM) for Operations and Maintenance personnel. Once the budget was 
received and approved, a Unit Manning Document was socialized and the Air Eorce 
began assigning personnel that have the right skill sets and experience to operate the 
system. The manning request and allocation process took a significant amount of time. 
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and at a basic level, only acquired the people at the operational locations in the positions 
they are intended to fill. This took around 1.5 years of planning and did not account for 
the system specific training that the space operations crews needed prior to arriving to 1/7 
SOPS. 



Blue Suit Transition 



• 1/7 SOPS embedded with CTR development activities 


• Exercises and Rehearsals, Data Compatibility Tests, CTR crew training. Routine Ops 


L ~L+60 ~L+180 ~L+270 -L+365 




Figure 10. Transition Timeline Blue-Suit to Contractor. Source: Thompson 

(2009). 


9. Facilities and Infrastructure 

Facilities and infrastructure experienced minimal change as part of the system 
evolution from contractor to Blue Suit operations. The plan since program inception was 
to operate out of a U.S. installation (Schriever AFB) with limited contractor facilities 
support and no facilities location change was necessary as a result of assigning 1 or 7 
SOPS as the operational owner. The location was always planned at MOD 10, and any 
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associated depot support and test facilities in support of MOD 10 would have been 
required regardless of the whether the system was contractor operated or maintained. 

However, there were modifications to existing facilities required to accommodate 
some of the Blue Suit operations and maintenance training. This included training and 
test terminals that were installed at the depot to provide off-line training when Space 
Operations training assets were unavailable to train Air Force operators. This also, for a 
short time, included test and training connections to the Sustainment LAN at the SOC 
(which was dual proposed as a training system). Additionally, and while not necessarily 
specific to Blue Suit Operations, a more robust space vehicle simulation suite was added 
to the SOC (Mission and Space Vehicle Simulators) to provide a more realistic training 
system for use by Blue Suit Operators when conducting off-line system training. 

10. Computer Resources 

Computer resources at the operational location weren’t necessarily affected by the 
change to Blue Suit operations, but as already mentioned, additional resources were 
added to the Space Operations Center to accommodate Blue Suit training. This included 
the more robust SV simulator (an entire new rack of computer equipment) and the 
institution of a Training Virtual Local Area Network, also referred to as the Sustainment 
LAN. Although these assets are key training components for Air Force operators, many 
of the contractor personnel were part of the system design team and generated many of 
the contractor operations procedures and tools needed for them to train on the system. 

B. SECONDARY RESEARCH: ACQUISITION LOGISTICS AND 

SUSTAINMENT CHALLENGES PRESENTED BY THE CHANGE IN 

SBSS BLOCK 10 SYSTEM SECURITY LEVEL 

This section presents the 10 core PSEs analyzed for the SBSS Block 10 System 
and the qualitative impacts to the secondary research question presented earlier in 
Chapter III. For this particular section, no mention of specific classification levels will be 
mentioned, only the changes required of the SBSS Block 10 program due to the change in 
security levels. 


35 



1. Sustainment Engineering 

Sustainment engineering was definitely impacted by the change in system security 
level. Maintenance data was required to be collected, maintained, and reported on a 
different classification of Maintenance Data Collection System. Also, anomaly 
resolution processes and discrepancy reporting procedures had to be adjusted to ensure 
that during any system anomaly or discrepancy data (and supporting corrective and 
support actions) were communicated and maintained at the appropriate classification 
levels. Additional consideration for system upgrades and technology refresh options was 
needed, ensuring any added external interfaces or new system hardware/software was 
encrypted and protected at the proper classification levels. 

SBSS Block 10 System Maintenance Data was always expected to maintained by 
the contractor and reported in accordance with approved SOC standards, but the change 
in classification added a new wrinkle. Maintenance data needed to be moved to different 
maintenance data system called LIONS (Nelson, 2010, Slide 7). Any communications 
for anomalies and discrepancies had to be communicated over appropriate secure phones 
or computer networks that were at the same level of the reported anomaly or discrepancy 
and any new system hardware or upgrades not only had to meet the strict technical 
requirements to meet/exceed mission requirements, but also had to be accredited and 
certified to the same standard. 

2. Supply Support 

Supporting SBSS Block 10 became a bit more challenging with the evolution in 
the security environment. Any supply assets entering the SOC or associated support 
facilities required additional review and scrutiny, at the points of receipt, as well as prior 
to entering any operational environment. Also, supply assets requiring repair underwent a 
rigorous review and sanitization effort prior to leaving the SBSS Block 10 Space 
Operations Center or associated support facilities. Any mission assets entering the 
disposal phase required a significant sanitization and/or destruction phase. Between asset 
review, sanitization, and disposal actions, outside of an emergency protocols, supply 
support for the SBSS Block 10 could be delayed an extra 3-5 days. 
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3. Maintenance Planning and Management 

The maintenance planning and management function wasn’t too affected by the 
change in security level. Since almost all maintenance for SBSS Block 10 was done in 
secured ground facilities (with the exception of SV software maintenance patches), there 
was little to no impact to on-equipment maintenance actions. There was some additional 
security coordination required to move any system patches on disk that couldn’t be sent 
via email, but procedures for moving software had been established and were already in 
place for all units occupying a MOD on Schriever AFB. Maintenance actions on SBSS 
Block 10 could also take longer due to additional security and approval steps required 
before maintenance could begin and end, as well as additional security steps that may 
have been needed during patch installation or server removal processes. Overall, 
however, changes to maintenance due to security level were manageable. 

4. Packaging, Handling, Storage, and Transportation (PHS&T) 

The Package, Handling, Storage, and Transportation functions experienced some 
changes as a result of the change in security level. Whether it was a simple change to how 
components were readied for shipment or as complex as how an asset should be sanitized 
or destroyed upon disconnection from the SBSS Block 10 mission system, additional 
considerations were notable. 

Packaging and Handling program assets or system components for SBSS Block 
10 took special care and consideration. Packaging changes focused especially on ensuring 
accurate security markings on both the asset itself and the packaging used to move the 
asset. Handling of certain mission assets could only be done by properly approved and 
personnel cleared to the correct security levels. Handling throughout the SOC was 
typically done at the same security level, however, certain material handling needed to be 
restricted to designated locations in the SOC. 

Storage and Transportation mechanisms also needed to be adjusted. Heavy duty 
safes constructed to specific DOD standards were required for specific system hard 
drives, and any mission system or support media needed to catalogued, tracked, and 
properly accounted for (by an assigned media custodian) until it was destroyed. 
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Additional secure taping and locking mechanisms were required for moving mission 
system and support assets from one location to another. Some transportation movements 
also now required more than one courier, increasing manpower needed for carriage of 
items from one geographic location to another. 

5. Technical Data 

Technical Data management was also a special consideration for security once the 
SBSS Block 10 system began system operations. While many process checklists could 
remain at a lower classification level, there were checklists and support documentation 
needed to adjusted to account for the appropriate classification. Some of these changes 
were as simple as an adjustment in security markings, yet others required changes in how 
these assets were managed, both inside and outside of the MOD 10 SOC. 

Initial operations procedures for contractor operations were generic in nature and 
generated mainly to support the planned support concept for contractor operations and 
support. Once the security level changed, these operations procedures needed to be 
reviewed and moved to an Air Force managed network at a different classification of 
network. Any changes to these procedures required approval not only through the USAF 
Operations, Training, and Maintenance Flights, but required additional approval through 
the agency security offices (Schumacher, 2009, p. 12). 

6. Support Equipment 

Support equipment for SBSS Block 10, regardless of security posture, did not 
vary significantly. As outlined earlier, most system support equipment is standard to most 
space ground systems and most of this equipment is commercially available (servers, 
computers, cables, racks, etc.) in their design and standard and non-unique support 
equipment is built-in by default (oscilloscopes, multi-meters, etc.). The only major 
change is how this support equipment was handled once it was introduced into a specific 
security environment. Any support equipment was required only to be kept at the initial 
introduction location (operations or maintenance) and any movement required significant 
review or desensitization procedures or destruction if entering the disposal phase. 
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7. Training and Training Support 

Training due to security level was affected, but mainly up-front and for new 
personnel that had not been exposed prior to certain security levels. Since almost all of 
the USG personnel involved in 1/7 SOPS and PMO’s were already operating at the 
required security levels, very little training on security changes was required with the 
exception of small amounts of training that may have been required due to new hardware 
introduced as part of the security change. Numerous contractor personnel also were hired 
or had history at the required security levels, so typically, that training was also minimal. 
Occasionally, personnel required re-training on SOC or GSOL security processes and 
procedures, but this was often done with little to no effect to daily operations tempo. 

8. Manpower and Personnel 

The manpower and personnel requirements grew considerably when SBSS Block 
10 security levels changed. The changes to the program were vast, affecting both the 
USAF and DOD organizations and development contractors. The manpower footprint 
grew substantially across the enterprise, costing the SBSS Block 10 operations and 
support programs precious time and effort while ensuring properly cleared personnel for 
operations across the SBSS enterprise. It was always suspected the both the contractor 
and Blue Suit manpower footprint would grow as the launch date grew closer, the 
security level change added many new requirements that further complicated the 
manpower and personnel requirement. 

SBSS Block 10 required the proper security clearances for all individuals (Blue 
Suit and contractor) that operated and maintained the system. This clearance was required 
for all of those on the operations floor, maintenance back shops, depot facilities, and 
factory support locations. Since all locations supporting SBSS Block 10 were at the same 
security level, all individuals working in these facilities needed to properly vetted and 
cleared. Additionally, proper clearance was vital for those USG personnel supporting 
acquisition and development actions at the Program Offices and Headquarters 
organizations supporting Block 10. In addition to all support personnel, more security 
personnel were needed to manage security accesses and visitor requests at all locations. 
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As suspected, the timelines for obtaining proper security clearances could be 
significant, requiring both the contractor and USAF to begin hiring and vetting actions 
for multiple job/position candidates in case discrepancies were noted during background 
investigations that disqualified candidates. Because security clearance vetting was 
handled by the Office of Personnel Management, clearance actions could be back-logged 
months or even years, significantly limiting the work that those were hired and waiting 
this clearance. While the SBSS Block 10 goal was to hire people with the proper 
clearances from the program inception, even those with the proper designation required 
additional vetting. Some personnel that had been with the program had to be pulled away 
and allocated to other non-SBSS mission tasks while they waited for the appropriate 
security clearances to be awarded. 

9. Facilities and Infrastructure 

The change in security environment probably had one of largest impacts on the 
Facilities and infrastructure required to support the SBSS Block 10 program. The impacts 
included significant facility modifications at multiple locations, to include significant IT 
infrastructure changes required to support the transfer of higher security files from one 
location to another. These changes were not just required of the Satellite Operations 
Center (SOC), but across the enterprise supporting the SOC (Vigil, 2010, Slide 2). 

As the development of the SBSS Block 10 program progressed, the interest from 
customers across the SSA enterprise increased. This interest morphed into evolved and 
derived system requirements, leading to the development of capabilities and interfaces 
required to support those customers, most to them requiring their mission data to be 
delivered at various security levels. These changes in customer included modifications 
to the hardware required at the operational location, changes to the link/data 
infrastructure, and facility modifications at both the operational location and depot/test/ 
integration facilities. 

The data link infrastructure changes to accommodate the security level of all of 
the customers SBSS Block 10 supports evolved as more customers were added and the 
mission set for SBSS Block 10 grew. All links within MOD 10 and Schriever AFB 
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required appropriate encryption and because customer and depot support facilities were 
spread across the country, the links needed to be properly encrypted and data pipelines 
established with all potential customers at the correct security levels (Vigil, 2010, Slide 
2). The links needed to be protected not only at the SBSS Block 10 MOD and support 
SBSS support facilities, but they also needed to be protected at any external customer 
facilities on their receiving nodes. 

The facility modifications at MOD 10 at Schriever AFB didn’t significantly 
change in the security level. The real changes required were needed at locations that 
supported the sustainment and support for the SBSS Block 10 Facility such as, the 
Ground Systems Operations Lab in Colorado Springs, the Space Vehicle Factory in 
Boulder, and to a lesser extent, the software support facilities in MIT Lincoln Labs in 
Boston, Massachusetts. The facility changes varied from changes in clearance for server 
heights and separate of mission support assets to changes in the type of doors and alarms 
needed to protect the facilities. These changes were also required across the enterprise, 
from the Factory locations to the local support/reach back facility in the Colorado 
Springs. Additionally, as Government depots at Hill AFB, Utah were brought online 
through the Depot Activation process, robust facility modifications to accommodate 
supporting SBSS Block 10 were also required. 

10. Computer Resources 

Changes to the computer hardware and software due to security level change were 
notable. Multiple racks of hardware were added to the MOD 10 equipment room floor, 
not only to support the evolving customer base, but to support the transfer of data to 
multiple test and support locations at the proper security level. The hardware expense 
alone was a multi-million-dollar investment, requiring the purchase of expensive servers 
and cryptology and specialized/modified test equipment to ensure data was stored on all 
hardware at the appropriate security levels. The hardware needed also included 
workstations to share data across multiple, already established DOD networks, as well as 
hardware needed to test at the proper security level before introducing to the operational 
system. 
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System software also required modifications to support the change in security 
level. Multiple software algorithms needed to be developed to accommodate the new 
cryptology devices, as well significant modifications to the Mission Planning and 
Mission Data Processing modules. Software interfaces for external customers were 
created as well, both internal to the SBSS Block 10 System, as well as the unaccounted 
for program costs experienced by any customer receiving data from SBSS Block 10. 

C. SUMMARY 

This Chapter provided the qualitative provided the qualitative analysis for each of 
the core 10 PSEs for SBSS Block 10 in relation to the primary and secondary research 
questions presented earlier in the Chapter. The next chapter will provide the findings and 
results. 
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IV. FINDINGS AND RESULTS 


Chapter III provided the qualitative analysis for each of the core 10 PSEs for 
SBSS Block 10 in relation to the primary and secondary research questions posed in 
Chapter 1. This Chapter will detail the General Findings and Results based on the data of 
Chapter III. While it can be difficult to say which changes were the most impactful to the 
logistics and sustainment baselines since all Product Support Elements were affected in 
some form or fashion, the findings below present general findings in relation to the 
primary and secondary research questions. 

A. PRIMARY RESEARCH FINDINGS: FINDINGS RELATED TO THE 
CHALLENGES OF TRANSITIONING SBSS BLOCK 10 FROM 
CONTRACTOR TO BLUE SUIT OPERATIONS 

Primary research Question Number 1 asks what challenges arose for effective 
SBSS Block 10 life cycle acquisition logistics and sustainability evolved as a result of the 
planned transition from a contractor operated system to a USG/Blue Suit Operations. 

As outlined in Chapter III, each of the core 10 PSEs had qualitative impacts to 
their implementation. Some, like supply support and computer resources, had only a few 
minor process changes or other smaller impacts that needed to be addressed. Others like 
the Manpower and Personnel, Training and Training Support, and Technical Data PSEs 
had more significant impacts, from creating brand new operations and training 
documentation to bringing in 33 new USAF personnel. Because of the time needed to 
create new systems documentation, training, and sourcing a significant number of new 1 
and 7 SOPS personnel, it can be argued that these PSEs were impacted the most. 

B. SECONDARY RESEARCH FINDINGS: FINDINGS RELATED TO 
SECURITY LEVEL CHANGE IMPACTS ON SYSTEM 
SUSTAINABILITY 

Primary research Question Number 2 asks what logistics and sustainment 
challenges were presented to the SBSS Block 10 System by the change in security level. 
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As outlined in Chapter III, each of the core 10 PSEs were also affected by the 
change in security level. The impacts were a bit more diverse, with arguably the greatest 
impacts felt across the Life Cycle Sustainment Management, Technical Management, and 
Infrastructure Management components, specifically, the Facilities and Infrastructure, 
Manpower and Personnel, and Computer Resources functions. Because of the significant 
time and resources it takes to hire cleared personnel (for both contractor and Blue Suit), 
purchase new equipment to ensure proper security of system assets, and set up and 
modify new facilities to accommodate the change in security level, there is strong case 
that these elements were affected more than others. 

C. OTHER FINDINGS: PRODUCT SUPPORT MANAGEMENT AND 

DESIGN INTERFACE 

Because of the overarching nature of the Product Support Management and 
Design Interface functions, these PSEs were not covered in detail in either qualitative 
analysis in Chapter III. However, it doesn’t make these components any less important. A 
Product Support Manager must consider all changes to these PSEs and then work with 
the PM’s to understand the affects to system cost, schedule, and performance and adjust 
the support posture to ensure a supportable system. Design Interface could be impacted 
by many of the changes made to all of these PSEs, with much of design changes 
experienced with new link interfaces, facilities, and equipment. 

D. SUMMARY 

This chapter discussed the findings from the data presented from Chapter III. It 
was found that perhaps the biggest changes to the PSEs for SBSS Block in reference to 
the primary research question had the most to deal with Technical Management and 
Infrastructure management components, specifically. Manpower and Personnel, Training 
and Training Support, and Technical Data PSEs. For the secondary research question 
related to impacts of system sustainability due to change in security level, the largest 
impacts were a bit more diverse, with the greatest impacts felt across the Life Cycle 
Sustainment Management, Technical Management, and Infrastructure Management 
components, specifically, the Facilities and Infrastructure, Manpower and Personnel, 
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Computer Resources, and Packaging, Handling, Storage and Transportation. The 
conclusions and recommendations from these findings will be presented in the final 
chapter, as well opportunities for future research. 
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V. CONCLUSIONS, RECOMMENDATIONS, SUMMARY AND 
AREAS FOR FURTHER RESEARCH 

A. CONCLUSIONS AND RECOMMENDATIONS 

The findings from this research can lead to a few conclusions about the impacts 
on the SBSS Block 10 PSEs, and subsequently, the acquisition logistics and sustainment, 
due to the transition from contractor to Blue Suit operations and changes to system 
security level. 

First, we can see that the logistics requirements for United States Government 
personnel operating a system can be more detailed and specific than for a contractor 
operating a space system. Whether it’s due to the level of education, experience, or 
turnover of USAF Blue Suit personnel or specific operational/maintenance personnel 
nuances, evolving from a contractor Operated System to a Blue Suit Operated System is 
no small task. Numerous considerations must be accounted for, from the type of 
personnel needed and the background needed to operate the system, to the processes the 
procedures that need to be modified or adjusted to account for the incorporation of any 
Blue Suit operations elements. 

Second, we can see that security level change impacts are also not insignificant 
and are vast across the acquisition logistics and sustainment enterprises. While SBSS 
Block 10 was able to overcome many of these challenges, on other programs, the amount 
of time and assets required to address a change in security level could lead to significant 
program delays. It can take up to 1 year or longer at times to clear or source appropriate 
Blue Suit and contractor personnel, creating significant delays if a change to USAF 
operations is made late in a system development life cycle. While the personnel change 
impact can be huge, facilities and hardware required to support a security level is equally 
as significant, especially since facility modifications can take anywhere from 6-18 
months, as well as the procurement, certification, and accreditation of any hardware that 
must be procured to support the change in security level. 
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Third, while both transition to Blue Suit Ops and the changes of security level 
impacted all core PSEs, arguably the biggest change experienced by the Manpower and 
Personnel piece of the logistics puzzle. The Blue Suit impact was mostly displayed by the 
increased “in-place’7transition times and the increase in the time that both contractor and 
Blue Suit personnel were on the Operations Floor. To accommodate new SBSS ground 
crews at the appropriate security level, Training and Technical Data Documentation 
needed to authored to proper education and experience level by new Blue Suit personnel 
and maintained at the appropriate security level. Finally, additional manpower (in 
addition to contractor personnel already hired and working) increased by 33 positions, 
with a significant increase also to the Security Manpower required across the portfolio. 

B. SUMMARY 

This research provides a qualitative analysis of the logistics impacts, effects, and 
sustainment challenges presented to Space Based Space Surveillance Block 10 System. 
Two large program changes were the focus of this study: a change in operations concept 
from a contractor operated to a USG/Blue Suit operations system and a change in system 
security level. The qualitative analysis/case study was conducted using the 10 core 
Product Support Elements (PSEs) as outlined in the Defense Acquisition University’s 
Integrated Product Support Element Guidebook. 

C. AREAS FOR FURTHER RESEARCH 

One area that could be further researched is the analysis of any potential schedule 
impacts/delays that could be directly tracked to the change in operations concept or 
security posture. While we know that SBSS Block 10 experienced many schedule delays, 
we can’t specifically attribute any of these to to the PSE changes experienced as a result 
of the operations concept and security level system changes. Euckily, SBSS Block 10 
System PSE changes brought on by the change in operations concept and security level 
coincided with other technical system challenges related to both the SV and EV, so they 
were able to be solved as other system challenges were also being addressed by the 
engineering and launch Integrated Product Teams. However, if either of these presented 
system changes were experienced independent of SV and EV challenges (and subsequent 
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delays caused by these challenges), it could be added value to illustrate (qualitatively and 
quantitatively) how these changes could have impacted both the launch and operations 
preparations needed to effectively man and operation the SBSS Block 10 System. 

Another area for additional research is system cost data analysis to further detail 
any potential manpower cost impacts directly attributable to the change in operations 
concept, both from a pre-launch and a life cycle cost perspective. Presented below is a 
life cycle cost chart table for both the operations and maintenance areas of SBSS Block 
10 that outline general post-launch costs for contractor operations and maintenance 
activities (Ward, 2016). 

Table 1. SBSS Manpower Life-Cycle Cost Estimate. Source: Ward (2016). 


Contractor Operations and Logistics Support 
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Again, any cost impacts brought on by the change of operations concept and 
security level are difficult to track because they also coincided with delays introduced by 
SV and LV technical challenges, not necessarily any changes to systems operations 
readiness by contractors/USAF personnel or security support posture for pre-/post-launch 
operations. However, the above life cycle cost chart accompanied with more detailed 
front end cost data could expose some costs that may have been avoided if Blue Suit 
operations were identified sooner or if the security levels were better known at program 
inception. 
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